In contemporary operating systems such as Microsoft® Corporation's Windows® operating systems, applications rely on system files, including those in the form of dynamic link libraries (DLLs) or the like, for various features and/or application programming interfaces (APIs). To ensure that an operating system is stable, the operating system code and system files are exhaustively tested, debugged and verified, resulting in particular versions of system files known to be highly stable. Those particular versions of system files are then shipped with the operating system.
However, because applications rely on system files, of which hundreds of thousands may be available, applications often ship versions of system files (e.g., DLLs) therewith that the application is known to work with, often because the application vendor has no idea as to what operating system the application will be installed under. Installing application software thus results in the installation of various versions of operating system DLLs and executables to a user's computer, some of which may be incompatible with the operating system and/or other applications on the system. This mismatched set of components causes an unknown and unreliable state to exist on the user's computer, a problem often referred to in the industry as “DLL Hell.”
By way of example, consider a user who installs an operating system such as Windows® 2000 on a given computer, and later starts browsing the web with that computer. While browsing the web, an interesting software application is found, downloaded to the computer, and then installed. However, during the installation, the application installer replaces the known, stable copy of MSVCRT.DLL that is in the user's system directory, with an earlier, or possibly later (and thus possibly untested), version. In many instances, the copy of the DLL that is installed is not fully compatible with the operating system and/or other applications already installed on the user's computer.
As a result, the user's computer will sometimes fail and =become less reliable, both in the operating system and in applications. One solution has been to use versioning techniques for system files, e.g., never copy over a higher-numbered version of a DLL. However, this has its own drawbacks, because version stamping is often done incorrectly, e.g., the versions are not properly identified in the DLLs relative to other versions. Moreover, for proper operation, providing new versions requires that those versions are backwards compatible, which even when it could be done correctly, is very difficult to get anyone to put into practice. Removing the application that is suspected of having made a system unstable does not eliminate this problem, and often the user's only recourse to an unstable system is to reinstall the operating system, and sometimes reinstall some of the applications.
Some systems prevent upgrading of system files by using file system security to prevent modification. This falls short because typically, the administrator (or power user) is the person installing the new application, which means that the user is allowed to modify the files. Also, system upgrades/patches are more difficult, since the security prevents correct and desired modifications of system files.